Deployed servers today may typically contain, on top of the operating system they run, many third party components, also referred to as dependencies. Most prominent example of such third party components may be open source components. The third party components may be curated in and consumed through repositories maintained by the operating system provider. Examples of such repositories may be: Yellowdog Updater, Modified (YUM) running on RedHat™ & Fedora™ Linux operating systems, Advanced Packaging Tool (APT) on Ubuntu™ and other Debian™ Linux systems, or Microsoft™'s OneGet/PackageManagement system.
In some exemplary embodiments, a deployed server may include hundreds, if not thousands, such dependencies. The dependencies may be included in the form of binary libraries or executable files, or other forms. Examples of such components may include the Apache™ web server, OpenSSL™ library, ImageMagick™ binary and library, and the bash terminal shell.
Dependencies may have flaws, such as security bugs, vulnerabilities, license flaws, or the like. New flaws may be discovered and disclosed on different dependencies at an inconsistent pace. However, since a typical server consumes many such dependencies, there may be a constant stream of relevant newly disclosed flaws on components run by such a server, requiring updates or patching to the components now known to be flawed.
When the frequency of flaw disclosure is combined with the massive and growing adoption of those components across the Internet, and the sheer number of servers every organization manages, it is very hard for organization to systematically and continuously protect themselves from flawed dependencies.
dependencies having security flaws may be one of the top security threats on the web today. Reports from Verizon™ and others state that the vast majority of successful exploits today are caused by “unpatched servers”—servers that did not consume the latest security fixes. Symantec™ estimates that by 2020, 99% of successful exploits will be caused by vulnerabilities that have been publicly known for over a year.
This need led to the existence of various security products, including a class of products referred to as Infrastructure Monitoring tools. The Infrastructure Monitoring tools may track which dependencies (and typically, Open Source Software (OSS) dependencies) are installed on each server, correlate them to known vulnerabilities and alert (or at times remediate) accordingly. Examples of Infrastructure Monitoring tools may be Tanium™, New Relic™ Infrastructure Monitoring.
In addition, each dependency may be covered by a different legal-binding license which may affect the rights and commitments of the owner of the deployed application that incorporated the dependencies, such as in case of copy-left licenses, licenses requiring attribution, licenses requiring the owner to provide a royalty-free license for her patents, or the like. As a result, the dependency may be considered flawed as it may impose limitations on the owner of the application.